home *** CD-ROM | disk | FTP | other *** search
- Path: phoenix.rhein.de!yaps!arno
- From: arno@yaps.rhein.de (Arno Eigenwillig)
- Newsgroups: comp.std.c
- Subject: Re: Alignment of malloc()
- Message-ID: <WwvTx*SVe@yaps.rhein.de>
- Date: Wed, 03 Jan 1996 07:58:50 +0100
- References: <DKDA7D.Kw7@midway.uchicago.edu> <j66Sx*FRe@yaps.rhein.de> <DKKHCH.L6r@midway.uchicago.edu>
- Organization: Yet Another Private Site in Meckenheim, Germany
- X-Copyright: This article may not be distributed on a CD-ROM
- or in printed form without prior written consent of the author.
- X-Newsreader: Arn V 1.04
-
- In article <DKKHCH.L6r@midway.uchicago.edu>, Michael Spertu writes:
-
- > My question is what the committee means by the words "proper alignment".
-
- Aligned in a way so that the data can be accessed.
-
- > it means that I would have to align all malloc() returns according to
- > the size of the data in all portable code I write.
-
- Manual alignment is not portable! Better leave such low-level stuff to
- the compiler. I was merely commenting on the case where you want to
- trick a certain single compiler.
-
- > For this reason, the two possibilities are:
- > 1) All the texts (including K & R) are advocating code that is not reasonable
- > on (the most common) compliant implementations of C.
- > or
- > 2) 32 bit alignment of malloc() on PCs is not compliant.
-
- Wrong. I wish you had read what I and others wrote. ;)
-
- Speed *never* is relevant for compliance. By The Standard, strictly
- conforming C programs take input and produce output in a finite time,
- following the semantics of the abstract machine. Everything else
- depends on the quality of the compiler you use, but is beyond The
- Standard, and thus, beyond this group. I feel not like saying that a
- third time, though.
-
- -- __
- __/// Arno Eigenwillig /\ <arno@yaps.rhein.de> \/ PGP key
- \XX/ V+49-2225-5870 /\ <Arnooo @ #amigager> \/ available
-